Audit Trail Logs

Purpose

Audit Trail Logs provide a historical record of changes made to the system from the System Administration Tool and various other user interfaces and applications. It does this by recording certain actions (such as who logged in and when) and storing this information in a log. Use the logs to help with troubleshooting when problems arise and to determine who in a multi-administrator system is responsible for a particular change. The following is a list of the features supported by the Audit Trail facility:

• In general, all login/logut attempts and any action from any user interface or application connected to MiVoice Business that results in a change to the system database is logged. See Audited User Interfaces and Applications, and Audited Actions below for details. See also Login Types Audited.

• Audit trails are presented in this form for viewing. printing, and exporting. You can use the Scheduler to archive the Audit Trail Logs to an external FTP or SFTP server on a recurring basis. The information logged includes the user who performed the operation, operation type (Add, Change, Submit, etc.), date/time, application involved, and actual data changed.

• Logs can be viewed in this form as a continuous file going back 5000 log entries. Older entries are archived in xml files that can be exported for offboard viewing. See Log File Size and Location for details.

• Audit Trail Logs are included in the system backup.

Audited User Interfaces and Applications

The user interfaces and applications audited for database changes and logins/logouts are as follows:

• System Administration Tool

• Group Administration Tool

• Desktop Tool

• Mitel Integrated Configuration Wizard

• MiVoice Business Software Installer

• MiXML interfaces (internal and external)

• Integrated Directory Services

Audited Actions

The following operations are logged:

• When a user logs in (whether successfully or not) and out of MiVoice Business. See Login/Logout Types Audited for more information.

• Provisioning operations—adds, deletions, and changes to the configuration of a user or device.

• Maintenance commands that can augment data or change the status of resources on a switch.

• Scheduler operations.

• IDS operations.

The following are excluded from Audit Trail logs:

• Changes caused by a database Restore

• Changes caused by database migration during upgrade

• Changes caused by call processing

• Features invoked by feature key,  feature access code, or Superkey

• Password/PIN creation and changes

• MiTAI

NOTES

• Changes initiated by IDS are logged at the affected remote node(s) rather than collated into a single log at the node acting as the IDS contact point. So for example, IDS ‘Apply Updates’ action for 100 users would generate a single IDS log entry on the IDS contact point node containing all 100 users in the Action Data and when distributed through IDS reach-through would generate 100 individual log entries on the remote node(s).

• All records for a given Import action are logged in a separate entry.

• For forms that support Multi-Record Editing (MRE) each affected record for a given MRE action will be logged in an individual log entry.

• Pre-Save/Post-Save log entries for License and Options changes and Day/Night Service changes that were posted in the Maintenance logs prior to MCD Release 5.0 are now logged in the Audit Trail logs.

Login/Logout Types Audited

The following login and logout types are logged

• System Administration Tool Logins

• Group Administration Tool Logins

• Desktop Tool Logins

• Telnet E2T: Telnet to the Ethernet to TDM (E2T) processor to access a call control maintenance session

• Telnet RTC: Telnet to the Real Time Controller ( RTC) processor to access VX Works session

• FTP: File Transfer Protocol session to the RTC processor to access logs and files

• MiXML: MiXML management session

Example Login/Logout Log

Action Data

Information logged with each login/logout is as follows:

User Authenticated—either True if the login was successful or False if not.  Note that successful login indicates that the administrator entered the password correctly. It does not mean that the administrator was able to access the system, because all of the available sessions may be in use (see Session Availability below).

Session Availability—either True if a session is available for an administrator who has entered a valid user name and password or False: Login session is not available and the administrator, even if validated, cannot access the system. For example, an administrator can successfully login with the correct user name and password but fail to get access if the maximum number of sessions allowed for the selected tool has already been reached.

Session ID—The number of administrators that can access a particular system tool is limited by the maximum number of sessions supported by that tool:

• System Administration Tool: 5 sessions

• Group Administration Tool: 5 sessions

• E2T Telnet: 1 session

• RTC Telnet: 1 session

• Ftp: 4 sessions

• MiXML: 50 sessions

The Session ID numbers are only unique for the same type of system access. Therefore, you must use both the login type and the session ID to identify login and logout events from the same session or administrator.

Log File Size and Location

The Audit Trail logs are stored in the system database in a circular buffer format and in an XML file located in the /db/database/audit_trail/ directory. The name of the XML file is derived from the hostname of the controller as specified in the System IP Properties form and the date/time of is creation—for example, localhost_20100505192045.xml.

The log can hold a maximum of 5000 records. When the maximum is reached, the next record logged (#5001) replaces the oldest (#5000) in the form, while at the same time a new XML file with the same name but a later timestamp is started.

Field Descriptions